Fixes #4074.

When PACKWIZ_URL and LOAD_ENV_FROM_FILE are both set, the container sources the env file before packwiz writes it. start-configuration loads it during the configuration stage, before the deploy is dispatched. The packwiz installer runs later, in start-setupModpack, and writes pack files into /data, including any .env the pack ships. By that point the container has already sourced the previous file, or no file at all on a first run, so the pack's values never reach the rest of startup.

The fix re-runs loadEnvFromFile inside handlePackwiz once the installer succeeds, guarded on LOAD_ENV_FROM_FILE being set. start-setupModpack already sources start-utils, so the helper is in scope. The early load stays where it is, so TYPE and VERSION still resolve before the deploy is dispatched.

What changed:

• scripts/start-setupModpack: re-load the env file after the packwiz installer runs.
• docs/mods-and-plugins/packwiz.md: document the re-load, and note that TYPE and VERSION resolve earlier, so a pack .env can't set them (use LOAD_ENV_FROM_GENERIC_PACK or LOAD_ENV_FROM_ARCHIVE for that).

Behaviour only changes when both PACKWIZ_URL and LOAD_ENV_FROM_FILE are set. Existing setups behave the same.

To reproduce: serve a packwiz pack with a root .env (for example MOTD=from-packwiz), then run with EULA=TRUE TYPE=FABRIC PACKWIZ_URL=... LOAD_ENV_FROM_FILE=/data/.env on a clean /data. The resulting server.properties shows motd=from-packwiz; without this change it stays at the default. Updating the served .env and restarting picks up the new value.